The 80% of your app that should never be written by hand, or by an LLM

Every business application is mostly the same application. Users, roles, workspaces, navigation. A data layer with foreign keys and uniqueness constraints. Forms that validate. Permissions that gate. CRUD, audit trails, pagination. It is unglamorous, it is roughly 80% of the code, and it has exactly one correct shape given your schema. That last part is the whole argument.

Correct-by-construction beats plausible

An LLM is a magnificent tool for problems with many acceptable answers. The boring 80% is the opposite: there is one right permission model for your entities, one right migration, one right set of form bindings. "Plausible" is not a passing grade there. When you generate that layer with a copilot, you get output that looks right, compiles, and is subtly wrong in the eleven places you didn't read closely, and you pay tokens to re-derive it every time you touch it.

A compiler doesn't guess. Give it a typed domain schema and it emits the same correct data layer, the same permissions, the same routes, byte for byte, every run. Cost per regeneration: effectively zero. Drift between runs: none.

Schema as the contract

The trick is to make the schema the single source of truth and refuse to let anything downstream become a second one. Entities, relationships, and constraints live in one typed model. The data layer, the API, the RBAC grants, the forms, and the navigation are all projections of it. Change the schema, regenerate, and every projection moves together. There is no hand-edited migration to forget, no permission map that quietly diverges from the model it was supposed to enforce.

This is also why business rules belong in the schema's orbit and not scattered through controllers. We write validation and rules once as isomorphic TypeScript that runs in the browser and again as an API guard. One rule, enforced everywhere, generated from the same source.

Regenerate, don't refactor

The payoff shows up the second time. A per-app fix (a token-store change, a build-speed migration, a state-management upgrade) is normally a tax you pay once per application. On a factory you convert that fix into a templated step and it propagates to every generated app on the next run. You stop maintaining twenty codebases and start maintaining one template that emits twenty. We call the alternative the per-app farm tax, and killing it is the point.

So what is the AI for?

The 20% that's left is where judgment actually helps: planning, reviewing diffs, migrating messy legacy, understanding a document, resolving the small parts a spec underspecifies. That residual gets an agent: on our own inference, producing reviewable diffs in a harness, not drift. Determinism is a dial: the more rules the spec layer validates, the larger the byte-reproducible core and the smaller the residual the AI has to touch. Every rule captured is compute nobody pays for again.

Everyone can generate plausible code now. The moat is being able to regenerate the same correct business from a schema, evolve the schema, and regenerate without drift. Determinism where it must be exact; AI where it genuinely helps. That split is the company.